REMARKS 

Claims 1-4 and 6-19 were pending. 
Claims 1-4 and 6-19 are rejected. 
Claim 20 is new. 
Claims 1-4 and 6-20 are pending. 

Withdrawal of Final Rejection 

The Applicant requests that the Examiner withdraw the finality of this rejection. The 
Applicant reminds the Examiner that: 

"The examiner may withdraw the rejection of finally rejected claims. If new facts or 
reasons are presented such as to convince the examiner that the previously rejected claims are in 
fact allowable or patentable in the case of reexamination, then the final rejection should be 
withdrawn. Occasionally, the finality of a rejection may be withdrawn in order to apply a new 
ground of rejection." MPEP 706.07(e) Withdrawal of Final Rejection, General, 1f2. 

As we describe in further detail below, the Examiner should withdraw the finality of the 
rejection of the claims and apply new grounds of rejection for the following reasons: 

• With respect to claim 6, the Examiner is citing a SOCKET primitive that creates a 
communication end point for the claim element of receiving an incoming data packet. In 
addition, the Examiner is citing a CONNECT primitive that attempts to establish a 
connection for the claim element of associating a packet with a connection. Accordingly, 
the Examiner is not considering the claims as a whole and is distilling the claims down to 
a gist. 

• The Examiner has not identified in Tanenbaum where parameters in an incoming data 
packet are analyzed, let alone how the analysis depends on a type of service access point 
with respect to independent claim 1 1 . 

• With respect to claim 12, the Examiner cited packet routing priority for the priority of 
parameters used in analyzing a data packet. Packet routing priority is not equivalent to 
priority of parameters for packet analysis. 

Accordingly, the Applicant requests that the Examiner withdraw the finality of the 
rejection. 
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Claim Rejections - 35 USC §102 

Claims 1 1-12 are rejected under 35 USC 102(b) as being anticipated by Andrew S. 
Tanenbaum, "Computer Networks," Third Edition 1996 ("Tanenbaum"). 
Claim 11 

Claim 1 1 includes analyzing a set of parameters in an incoming data packet, wherein the 
set of parameters analyzed depends upon a type of service access point from which the data 
packet came." 

The Examiner has identified the set of parameters as the parameters of an IP packet 
header and the data packet as an IP packet. However, the Examiner has not identified in 
Tanenbaum where these parameters are analyzed, let alone how the analysis depends on a type of 
service access point. 

Tanenbaum defines a service access point as a place where a layer n offers services to a 
layer n+1. Tanenbaum, p. 1 1. Thus, the data packet from a service access point must have come 
from layer n to layer n+1 or vice versa. As can be seen in Fig. 1-1 1 the data that is transmitted 
between layers 4 and 5 is data M, not header H4. Thus, in layer 4, parameters of M alone must 
be analyzed. Referring back to the Examiner's example of the IP packet, there is no teaching 
that the payload of the IP packet is analyzed, let alone analyzed based on the type of the service 
access point. 

Moreover, claim 1 1 includes "if the set of parameters in the data packet match a 
predefined set of parameters associated with a connection identifier, associating the connection 
identifier for the predefined set of parameters with the packet." Thus, a connection identifier is 
associated with the packet if the parameters in the packet match parameters associated with a 
connection identifier. 

The Examiner identified the identification, source address, and destination address of the 
IP packet header as the connection identifier. However, these are all fields that are associated 
with an IP service access point, not a connection after data has been received from an IP service 
access point. (See Tanenbaum, p. 489, an IP address is an example of a network service access 
point.) Thus, the address in the IP header becomes associated with the data packet because of 
the service access point, not in response to some matching of parameters in the data packet. 

Accordingly, Tanenbaum does not teach each and every element of claim 1 1 and 
dependent claim 12. 
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Claim 12 

Claim 12 includes "analyzing the data packet according to a plurality of sets of 
parameters, each set of parameters including a priority; wherein the sets of parameters are used 
in analyzing the data packet in order of priority." Thus, multiple sets of parameters, each with a 
priority, are analyzed in the data packet. The order of the analysis depends on the priority of the 
set. 

The Examiner cited the "precedence field" which allows routers to make choices between 
various links. Tanenbaum, p. 414. However, it is the order of the analysis of the parameters that 
is determined by the priority, not the order of the packets when routed. Assume for the sake of 
argument that the sets of parameters to be analyzed are the fields of the IP packet header as cited 
by the Examiner. Assume that the source and destination address are a first set of parameters 
and the total length and checksum are a second set of parameters. Thus, to anticipate claim 12, 
not only must a priority be associated with each set, but the parameters must be analyzed in order 
of that priority. There is no indication that analysis of IP header fields depends on a priority 
associated with those fields. 

Accordingly, Tanenbaum does not teach each and every element of claim 12. 

Claim Rejections - 35 USC §103 

Claims 1-4, 14-19 are rejected under 35 USC 103(a) as being unpatentable over W. 
Richard Stevens, "UNIX Network Programming," 1990, ("Stevens"), in view of US Pub. No. 
2003/0103521 to Raphaeli ("Raphaeli") 
Claim 1 

Claim 1 includes "receiving application data from an application in a device through a 
service access point; classifying the application data as internet protocol (IP) based or non-IP 
based according to the associated service access point; and determining if a connection exists for 
the application data in response to the classification of the application data." Thus, the 
classification and the determination if a connection exists operates in response to application data 
received through the service access point. That is, the receiving, classification, and 
determination are all on the system side or downstream side of the service access point. 

In contrast, the Examiner cited various Berkeley Sockets system calls such as socket, 
connect, listen, accept, and the like. As these are system calls, they are on the application side of 



Docket No. 8371-156 



Page 8 of 12 



Application No. 10/663,866 



a socket, which was interpreted by the Examiner as the service access point. Thus, Stevens does 
not describe the operation of the system, rather the interface to the system through he system 
calls. 

Moreover, assuming for the sake of argument that the Berkeley Sockets system calls are 
used at the system level such as in accessing a lower protocol layer, Stevens still only describes 
the interface to a protocol layer, not the implementation. There is still no suggestion of using the 
family variable of a first socket call, cited by the Examiner as the classification of IP or non-IP, 
in another lower level socket related call. For example, if the family is set in an application level 
socket call, there is no suggestion that it is propagated to a lower level connect call as suggested 
by the Examiner. 

Furthermore, Raphaeli is silent on IP, instead describing a powerline MAC layer. Thus, 
it does not suggest using a classification as IP or non-IP in determining if a powerline MAC 
connection exists. As a result, the combination of Stevens and Raphaeli does not teach or 
suggest each and every element of claim 1 . 
Claims 14-16 

Each of claims 14-16 includes accessing a classification table for a mapping of the 
service access point to a connection identifier. Dependent claims 1 5 and 1 6 add additional 
elements for the mapping. Since the classification table includes a mapping of the service access 
point and the connection identifier, the service access point and the connection identifier are 
distinct. In parent claim 1 , application data is received through a service access point prior to 
determining if a connection exists for the application data. Thus, the connection is distinct from 
the service access point. 

In contrast, the Examiner is interpreting fields of a cited socket descriptor as both the 
service access point and the connection identifier. Stevens states that all elements of the 5 -tuple 
must be specified before the socket descriptor is of any real use. Stevens, p. 269. Thus, the 
socket descriptor must be fully described prior to receiving application data through the socket. 

The Examiner has give no rational reason why a connection created between the service 
access point and a remote service access point would be checked to see if it exists after the 
application data was received through the service access point. 

Moreover, in claim 1 5 at least one of an IP address, a port number, and a type of service 
field is used with the service access point in the mapping. In claim 1 6, both an IP address and a 
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port number are used with the service access point in the mapping. The Examiner's 
interpretation of the socket descriptor as both a service access point, at least one of an IP address, 
a port number, and a type of service field, and a connection identification makes the clause "at 
least one of an IP address, a port number, and a type of service field" meaningless. 

Note that removing the addresses of the socket descriptor leaves only the protocol field 
and the process fields. This is in direct conflict to Tanenbaum where the transport service access 
point (TSAP) is described with reference to the Internet as an IP address and a local port. 
Tanenbaum, p. 489. In other words, the IP addresses are part of the service access point. One 
skilled in the art would understand that the socket descriptor as a whole describes the socket. 
Thus an additional mapping of at least one of an IP address, a port number, and a type of service 
field and a connection identifier are needed. This additional mapping is not suggested by the 
combination of Stevens and Raphaeli. 

As a result, the combination of Stevens and Raphaeli does not teach or suggest each and 
every element of claims 14-16. 
Claims 17-19 

Claims 17-19 include comparison of the application data with particular classifier rules 
for a match. The Examiner cites the 5-tuple socket descriptor as values to be compared. 
However, nowhere in the cited section of Stevens is the socket descriptor described as being 
compared. Moreover, there is no suggestion of comparing the socket descriptor to the 
application data. , as described above the service access point adds what is in the header. 

For example, assume for the sake of argument that application data is received through an 
IP socket. If some IP address is not part of the application data, then it would not be compared 
against an IP address in the socket descriptor. Alternatively, as described above, the protocol 
layer adds a header to the data. Thus, an IP header would be added to data passing through an IP 
service access point. The IP address would be identical to the IP address in the socket descriptor. 
There would always be a match. One skilled in the art is not going to add unnecessary 
comparisons where there would always be a match as described by the Examiner. 

Moreover, in claim 19, the application data is only compared to "at least one destination 
address within the at least one classifier rule." The at least one classifier rule was introduced in 
claim 17 for providing a connection where there is a match between the application data and the 
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at least one rule. Hence, when providing a connection for the application data, the application 
data is compared with only at least one destination address before a connection is provided. 

In contrast, the Examiner cited the comparison at a receiving end socket. If the data has 
arrived at the receiving end, then a connection was already provided for the data to get to the 
receiving end. In addition, the Examiner has given no rational reason why the same classifier 
rule used at the originating end to identify a connection is used again at the receiving end. 

As a result, the combination of Stevens and Raphaeli does not teach or suggest each and 
every element of claims 17-19. 
Claim 6 

Claims 6-10 are rejected under 35 USC 103(a) as being unpatentable over Tanenbaum in 
view of Stevens. 

Claim 6 includes "receiving an incoming data packet from an application on a device at 
one of a plurality of service access points; and classifying the data packet according to the 
service access point and at least one rule, causing the packet to be associated with a connection." 

The Examiner cited the SOCKET and CONNECT primitives to show receiving the 
incoming data packet and associating the data packet with a connection. As can be seen in the 
cited Fig. 6-6, the SOCKET primitive creates a communication end point and the CONNECT 
primitive attempts to establish a connection. Tanenbaum, p. 487. Creating a communication end 
point (SOCKET) is not receiving an incoming data packet. Similarly, attempting to establish a 
connection (CONNECT) is not associating a packet with a connection. 

Moreover, connections as used in Tanenbaum are always between end point to end point, 
not from an end point up the protocol layers to an application. See Tanenbaum, p. 490. 
Assuming for the sake of argument that the Examiner meant to say that the RECEIVE primitive 
was receiving an incoming data packet, the characterization of the application data is in direct 
conflict with other claim elements. 

For example, if the data packet is received through a local socket, then there is no 
suggestion of routing the packet to the connection and transmitting the data. Tanenbaum and 
Stevens both describe the interface to a network layer looking into the network, not processing 
that occurs on received packets. 

As a result, the combination of Stevens and Tanenbaum does not teach or suggest each 
and every element of claims 6-10. 
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Claim 13 

Claim 13 is rejected under 35 USC 103(a) as being unpatentable over Tanenbaum. Claim 
1 includes "analyzing a set of parameters in an incoming data packet, wherein the set of 
parameters analyzed depends upon a type of service access point from which the data packet 
came." 

The Examiner cited option negotiation to show analyzing a set of parameters of an 
incoming packet. There is no suggestion that an incoming data packet is analyzed for the quality 
of service parameters described in Fig. 6-2. Tanenbaum, p. 482-483. The Examiner claimed that 
the option negotiation applies to socket parameters. However, the Examiner has given no 
rational reason why an incoming data packet is analyzed for negotiation of quality of service 
parameters of a connection, or even why socket parameters would be in an incoming data packet. 

As a result, the Tanenbaum does not teach or suggest each and every element of claim 13. 

For the foregoing reasons, reconsideration and allowance of claims 1-4 and 6-20 of the 
application as amended is requested. The Examiner is encouraged to telephone the undersigned 
at (503) 222-3613 if it appears that an interview would be helpful in advancing the case. 

Respectfully submitted, 

MARGER JOHNSON & McCOLLOM, P.C. 




Derek Meeker 
Reg. No. 53,313 
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